Date: Mon, 12 Apr 93 04:30:16 PDT 

From: Ham-Policy Mailing List and Newsgroup <ham-policy@ucsd.edu> 
Errors-To: Ham-Policy-Errors@UCSD.Edu 

Reply-To: Ham-Policy@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Policy Digest V93 #93 

To: Ham-Policy 


Ham-Policy Digest Mon, 12 Apr 93 Volume 93 : Issue 93 


Today's Topics: 
fido node regurgitating articles in rec.radio.amateur.* 
rec.radio.amateur reorg/RFD discussion summary 4/11 


Send Replies or notes for publication to: <Ham-Policy@UCSD.Edu> 
Send subscription requests to: <Ham-Policy-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Policy Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-policy". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Sat, 10 Apr 1993 17:10:23 GMT 

From: valinor.mythical.com!n5ial!jim@uunet.uu.net 

Subject: fido node regurgitating articles in rec.radio.amateur.* 
To: ham-policy@ucsd.edu 


please excuse the cross-posting, but I'm seeing this in all 3 r.r.a groups, 
so in this case, it seems appropriate....my apologies if this isn't a valid 
assumption (but then, the post actually only gets sent once either way, so 
it's not as if it generates any extra net.traffic or anything). 


it would seem that once again, there is a fido node somewhere that seems to 
think that the rest of the world wants to see duplicate copies of every 
single post. anyone know how to handle this? 


for example, in rec.radio.amateur.policy (when I finally decided I wasn't 
imagining things), I saw a post from greg@core.rose.hp.com (Greg Dolkas). 
a few articles later, guess what....that exact same post is repeated. 
however, this time the article claims to be from 
Greg.Dolkas@£716.n109.z1.his.com (Greg Dolkas). 


the last time I saw this was about a week ago in comp.os.linux, and it 


was a fido node that wasn't configured right, or something like that. 
the symptoms were identical, and just as could quickly become the case 
here, it was no doubt costing a lot of $$$ for some folks (a high-volume 
newsgroup is bad enough...but when someone decides to double that volume 
with duplicate postings, that's *REALLY* bad). 


anyone know how to proceed in getting these duplicates stopped? 


--jim 
d#include <std_disclaimer.h> 73 DE N5IAL (/4) 
INTERNET: jim@n5ial.mythical.com | j.graham@ieee.org ICBM: 30.23N 86.32W 
AMATEUR RADIO: n5ial@w4zbb (Ft. Walton Beach, FL) AMTOR SELCAL: NIAL 


Date: 11 Apr 93 12:21:36 GMT 

From: rtech!amdahl!amdahl!ikluft@decwrl.dec.com 

Subject: rec.radio.amateur reorg/RFD discussion summary 4/11 
To: ham-policy@ucsd.edu 


This article contains 5 subtopics: 
Current Status of the Discussion 
How to Participate in the Discussion 
Summary of RFD proposed newsgroups (Option I) 
Summary of RFD proposed newsgroups (Option II) 
Notes from the discussion so far 


Current Status of the Discussion 


The RFD (Request for Discussion) for the reorganization of rec.radio.amateur 
was posted on March 26 to news.announce.newgroups, news.groups, and all the 
subgroups of rec.radio.amateur. A summary of the proposed newsgroups can be 
found later in this article. 


We have passed the half-way point in the 30-day discussion period. Current 
tallies of opinions posted to news.groups are as follows: 

in favor: 25 people 93 articles 

opposed: 14 people 30 articles 

undecided or unclear: 10 people 18 articles 
(the "unclear" category only includes replies that were off the subject) 


These numbers may seem small by UseNet standards but it has actually been one 


of the larger of many ongoing discussions on news.groups. Support has been 
running around the 2-to-1 in favor area since the discussion started. Due 

to the support expressed, we expect that it will be possible to issue a CFV 
(Call for Votes) some time after the end of the discussion period, which will 
conclude on April 26, 1993. 


How to Participate in the Discussion 


If you have not yet expressed an opinion on the proposed split, you can make 
it easy on yourself by just replying to this article onto news.groups (the 
Followup-To line already specifies that for you) and say 

I support the reorganization of rec.radio.amateur 
or 

I do not support the reorganization of rec.radio.amateur 


YOUR REPLY MUST BE POSTED TO NEWS.GROUPS IN ORDER TO BE AN OFFICIAL PART OF 
THE NEWSGROUP CREATION PROCESS. You may cross-post to rec.radio.amateur.misc 
if you prefer to. 


It would be even more helpful, if you support the split of r.r.a.misc, to 
indicate which option from the RFD that you prefer. It's OK to say you like 
both. They are summarized below. You can still make things pretty easy for 
yourself by only posting 

I support the reorganization of rec.radio.amateur (Option I) 
or 

I support the reorganization of rec.radio.amateur (Option IT) 
or 

I support the reorganization of rec.radio.amateur (either option) 


Here's a question to ask yourself as you consider these proposals: 
Which proposal would make you more likely to vote for all the newsgroups 
when voting time arrives? (Separate concurrent votes will be held for 
each newsgroup in accordance with the newsgroup creation guidelines. ) 


Summary of RFD proposed newsgroups (Option I) 
(all groups unmoderated) 
Newsgroup name description 


rec.radio.amateur.misc all Ham radio topics not covered below 
i.e. video, stories, humor, new topics 
[no modification to existing newsgroup] 
rec.radio.amateur. policy regulations & policy issues 
[no modification to existing newsgroup] 
rec.radio.amateur.digital.misc packet radio & other digital modes 


rec.radio.amateur.digital.tcp-ip 
rec.radio.amateur.operating 


rec.radio.amateur. products 
rec.radio.amateur.instruction 
rec.radio.amateur.construction 
rec.radio.amateur.space 


rec.radio.amateur.emerg-services 


[includes old rec.radio.amateur. packet] 
TCP/IP via packet radio 

Operating procedures and questions: DX, 
CW, contests, propagation, repeaters 
manufactured equipment, modifications 
Ham radio instruction & examination 
homebrewing & experimentation 

amateur radio in space: satellites, 
earth-moon-earth (EME), shuttle, MIR 
emergency services: RACES, ARES, NTS 


Summary of RFD proposed newsgroups (Option II - "the .tech option") 


(all groups unmoderated) 
Newsgroup name 


rec.radio.amateur.misc 


rec.radio.amateur.policy 
rec.radio.amateur.digital.misc 


rec.radio.amateur.digital.tcp-ip 
rec.radio.amateur.operating 


rec.radio.amateur.emerg-services 
rec.radio.amateur.tech 


video 


Notes from the discussion so far 


all Ham radio topics not covered below 
i.e. video, stories, humor, new topics 
[no modification to existing newsgroup] 
regulations & policy issues 

[no modification to existing newsgroup] 
packet radio & other digital modes 
[includes old rec.radio.amateur. packet] 
TCP/IP via packet radio 

Operating procedures and questions: DX, 
CW, contests, propagation, repeaters 
emergency services: RACES, ARES, NTS 
Technical discussions about Ham Radio: 
construction, theory, examinations, 


The following notes may help you determine if any suggestions you are 


considering have already been discussed. 


Your opinion is important so be 


sure to show your support or opposition and make any suggestions you believe 
would help make this a better, more successful proposal. 


* There has been strong agreement that r.r.a.misc has too much traffic. 

*x One of the main points made by those opposing the split has been a concern 
that there may be a lot of cross-posting of articles across the proposed 
newsgroups. 1r.r.a.policy was commonly used as an example. 

* Rebuttal to the cross-posting argument pointed out that even in r.r.a.policy 
there is currently very little cross-posting. With numbers to show this was 
a misconception, one person withdrew opposition and began supporting the 


split. 

A point made by proponents of the split was that r.r.a.policy is not a good 
comparison. All the proposed newsgroups were modeled after r.r.a.packet, 
which was made for a subject that many Hams are interested in. r.r.a.policy 
was just a place to throw away an unwanted subject. Still others said that 
r.r.a.policy has plenty of ongoing policy-related discussion and has also 
worked pretty well. 

On the subject of cross-posting, there has been some discussion about a 
netiquette guide like that found on rec.aviation for the past several years. 
The idea may be considered regardless of the result of the vote. 

Some concern was expressed by both supporters and opposers about the 
Info-Hams mail list. A common concern was that the mail lists will need to 
match the newsgroups in order for this to work. Comments from Brian Kantor 
indicated a wait-and-see position. He did not rule out making new mail lists 
if the newsgroups pass but he is understandably not enthusiastic since he 
has plenty of other work to do. 

Two people questioned why the proposal includes making a subhierarchy for 
r.r.a.digital.misc and r.r.a.digital.tcp-ip. It was pointed out that these 
were requested by users of r.r.a.packet due to the explosion of new digital 
modes. There has been no opposition from the r.r.a.packet community. 

Most people supporting the split have not indicated which option (I or II) 
they support. It was noted that it's been difficult to determine which will 
be the most-likely-to-succeed choice to put on the CFV. 

Those who prefer Option I seem to do so because the newsgroup names are 
clearer and more focused. It was said that r.r.a.tech is too general to 
differentiate itself significantly from r.r.a.misc. So the advantage is 
that Option I avoids some confusion. (Option I adds 7 newsgroups) 

Those who prefer Option II (r.r.a.tech) seem to do so because it has fewer 
newsgroups than Option I while still offering an area for technical 
discussion away from r.r.a.misc. So the advantage is that Option II is not 
as large an increase in newsgroups. (Option II adds 5 newsgroups) 

A preference was stated to change r.r.a.products to r.r.a.equipment. 
Rebuttals said that would be confusing next to r.r.a.construction. The 
suggestion did not have enough support to be added to the proposal. 

A preference was stated to change r.r.a.construction to r.r.a.homebrewing. 
Rebuttals said that the name would not be clear enough to outsiders or 
newcomers. The suggestion did not have enough support to be added to the 
proposal. 

A preference was stated to change r.r.a.operating to r.r.a.dx. Rebuttals 
said this would eliminate coverage for many other aspects of operating 

a radio. (Notably, UHF/VHF repeaters.) Also, this was considered on the 
rra-reorg mail list prior to the RFD, where DX and repeaters were combined 
to make r.r.a.operating. Another suggestion was to add r.r.a.dx alongside 
r.Y¥.a.operating. The suggestion does not appear to have enough support but 
some discussion may continue. 

A preference was stated to add an r.r.a.bulletins newsgroup. No replies 
were made to a subsequent poll on the subject so the suggestion is assumed 
to have insufficient support. One problem was noted that it mostly overlaps 


rec.radio.info which serves all of rec.radio, including rec.radio.amateur.*. 
A couple articles suggested adding an r.r.a.flame newsgroup. Most 
participants seem to have assumed that was said tongue-in-cheek. It has not 
been taken seriously. 

r.Y¥.a.space appears to have significant support. It will probably be on the 
CFV (call for votes) whether Option I or II is selected as the final model. 
It was noted that this will mean that Option II will add 6 newsgroups 

instead of 5. (r.r.a.space was previously only on Option I.) 

A suggestion was made to add an RDF (radio direction finding) newsgroup to 
the proposal. The original suggestion was to call it r.r.a.jamming. Another 
article suggested a clearer name of r.r.a.rdf. An opposing opinion said 
there is not enough traffic to make a separate newsgroup for this topic. 

This subject is not done being discussed but does not yet have enough support 
in the discussion to add it to the proposal. 


Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 
[disclaimer: any opinions expressed are mine only... not those of my employer] 


End of Ham-Policy Digest V93 #93 
KAKKKKKKKKKKKKKKKKKKKEKKEKRER AKIRA 


